 [18:01:10] Join You have joined the channel #fedora-meeting (n=ltinkl@194.212.22.14).
 [18:01:11] Topic The channel topic is "Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule".
 [18:01:11] Topic The topic was set by f13 on 1.6.2009 20:54:11.
 [18:01:11] Mode Channel modes: no messages from outside, no colors allowed
 [18:01:11] Created This channel was created on 18.1.2007 20:10:56.
 [18:01:13] Join jreznik has joined this channel (n=jreznik@nat/redhat/x-aab30951cbb83538).
 [18:01:41] Join JSchmitt has joined this channel (n=s4504kr@fedora/JSchmitt).
 [18:01:42] Join tatica has joined this channel (n=tatica@nelug/designer/tatica).
 [18:02:16] <rdieter> KDE SIG Meeting start, who's present today?
 [18:02:22] * SMParrish here
 [18:02:24] * ltinkl here
 [18:02:29] <Kevin_Kofler> Present.
 [18:02:36] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- Init".
 [18:02:37] Part iarlyy has left this channel.
 [18:02:44] * jreznik is here
 [18:02:48] <than> present
 [18:02:50] * mefoster is back ...
 [18:02:55] <rdieter> than: welcome back
 [18:03:21] <than> i was back yesterday
 [18:03:35] <rdieter> well, agenda item 1, phonon-backend-gstreamer, to ship or not to ship, Kevin_Kofler ?
 [18:04:02] Join slipp3d has joined this channel (n=Slip@cmg-2-254.r15.mtwgln.infoave.net).
 [18:04:30] <ltinkl> ship it (MHO), there is nothing broken with it, I've been using it for some months already without any major problems
 [18:04:31] <Kevin_Kofler> Well, I guess the consensus is to keep shipping it, it's not the default anyway.
 [18:04:31] <MathStuf_> half here
 [18:04:54] <jreznik> my two cents - fedora is gstreamer based distro so ship it...
 [18:05:04] <than> we ship it but don't make it as default
 [18:05:19] <Kevin_Kofler> The thing is just: device selection is implemented in a strange way which bypasses the Phonon API, there's this fun bug: https://bugzilla.redhat.com/show_bug.cgi?id=503260 which is due to that, and the Amarok developers complain about several other bugs.
 [18:05:19] <buggbot> Bug 503260: medium, low, ---, than, ASSIGNED, qtconfig-qt4 does not recognize that gstreamer backend is around
 [18:05:59] <ltinkl> the bug itself is due to the way we compile Phonon right?
 [18:06:06] <Kevin_Kofler> That bug is because qtconfig-qt4 needs to link GStreamer directly to configure Phonon-GStreamer as the information from GStreamer is not abstracted properly by the backend.
 [18:06:09] <rdieter> ltinkl: how qt is built
 [18:06:11] <ltinkl> (not really a phonon.gstreamer bug)
 [18:06:37] <jreznik> I don't like several multimedia frameworks, it's better one and well supported - in fedora it's gstreamer...
 [18:06:41] <rdieter> side issue here is how to build/ship phonon, upstream still doesn't have a clear recommendation.
 [18:06:53] <rdieter> use qt's phonon, or kde/standalone phonon?
 [18:06:55] <Kevin_Kofler> We need to BR gstreamer-devel to fix that, and then qtconfig-qt4 will depend on GStreamer.
 [18:07:22] <rdieter> Kevin_Kofler: BR is all? that's acceptable... I thought the -gstreamer backend had to be built/enabled too.
 [18:07:29] <Kevin_Kofler> This is completely broken, the whole point of Phonon is that the UIs don't have to link a multimedia framework directly.
 [18:07:49] <Kevin_Kofler> rdieter: Most likely the backend has to be built or qtconfig's .pro file tweaked to fake it.
 [18:07:50] Quit openpercept has left this server ("Leaving").
 [18:07:55] <rdieter> oh ok.
 [18:07:57] <ltinkl> I agree with Kevin here, the backend abstraction isnt perfect here
 [18:08:17] <ltinkl> what bothers me more is which Phonon to ship?
 [18:08:27] <ltinkl> Qt or KDE's one?
 [18:08:38] <Kevin_Kofler> The underlying issue is that Phonon has only one level of devices, GStreamer has 2 ("sink" = the API used and "device" = the device accessed through that API).
 [18:08:39] <rdieter> seems other distros are starting to use qt's
 [18:08:39] <ltinkl> the KDE version hasn't seen any updates for quite some time
 [18:09:00] <Kevin_Kofler> And Phonon-GStreamer works around that with that backend-specific "sink" option.
 [18:09:18] <rdieter> and if using qt's phonon, what does that mean about phonon-backend-xine's maintainance/support
 [18:09:19] <Kevin_Kofler> xine-lib also has those 2 levels, but Phonon-Xine magically turns them into a flat list.
 [18:09:50] <ltinkl> phonon-backend-xine lives in kdesupport only?
 [18:09:56] <Kevin_Kofler> Which also means PulseAudio shows up as one device, you can't control where the output goes to through PulseAudio without going to pavucontrol or the like (not sure whether xine-lib would support it, but Phonon definitely doesn't).
 [18:10:05] <mefoster> Is that why there are so many weird options in the "multimedia" system-settings module?
 [18:10:17] <rdieter> Kevin_Kofler: I recall you having some discussions with (upstream?) folk to address that, but I suppose none of that led to any fruitful fixes yet?
 [18:10:27] Join MathStuf__ has joined this channel (n=MathStuf@c-71-58-177-177.hsd1.pa.comcast.net).
 [18:10:47] <Kevin_Kofler> ltinkl: Yes, Trolltech/Nokia refused to import it into their copy because xine-lib is GPL and so not acceptable for their commercial customers.
 [18:11:30] <jreznik> mefoster: it's really mess...
 [18:11:30] <Kevin_Kofler> rdieter: Right, my SoC project where I suggested to tackle that as well as KMix PA integration was rejected.
 [18:11:49] <Kevin_Kofler> Earlier discussions with Phonon upstream lead to people mostly agreeing with my suggestion, but no movement towards actually implementing it.
 [18:12:23] <rdieter> looks like we've got 2 issues at least to sort out: 1. how to build support phonon (qt or standalone), 2. depending on 1, how best to build/ship phonon backends
 [18:12:49] Join ChitleshGoorah has joined this channel (n=chitlesh@40.4-66-87.adsl-static.isp.belgacom.be).
 [18:12:51] <rdieter> any volunteers to own these items?
 [18:12:56] <Kevin_Kofler> mefoster: What weird options? You mean things like having both "PulseAudio" and "PulseAudio sound server"?
 [18:13:36] <mefoster> Kevin_Kofler: Yeah, and also "default" and about three different "Intel" things
 [18:13:37] <Kevin_Kofler> (Yes, that one is an artefact of the coalescing, the former is native PulseAudio which shows up as a single device, the latter is the ALSA pulse device which shows up as a device like the other ALSA devices.)
 [18:13:47] Quit MathStuf_ has left this server (Read error: 60 (Operation timed out)).
 [18:13:50] <Kevin_Kofler> mefoster: Those are the ALSA devices.
 [18:14:08] <Kevin_Kofler> Those and "PulseAudio sound server" should really be subitems of "ALSA" in a tree.
 [18:14:19] <Kevin_Kofler> And that interface would also allow fixing Phonon-GStreamer properly.
 [18:15:16] <Kevin_Kofler> We could "fix" it to work the way Phonon-xine now does, but it'd probably break some use cases the current implementation supports.
 [18:16:17] <rdieter> ok, I'll take ownership of the phonon issues, I guess. Kevin, do you have the time/interest to work on your fixing-phonon ideas?
 [18:16:18] <than> last time i tried to ask the phonon upstreamer, but did't get any answer!
 [18:17:03] <rdieter> than: me too, I was assured it would be sorted out for the kde-4.3 release, but that hasn't happened... yet. I'll make some louder noise, and see what happens
 [18:17:04] Join fbijlsma has joined this channel (n=fbijlsma@p54B2DFBA.dip.t-dialin.net).
 [18:17:09] <Kevin_Kofler> I may end up using some of my free time in the future to fix this properly if the current mess annoys me enough, but I don't have much time and it's a lot of work to fix it properly.
 [18:17:27] <rdieter> Kevin_Kofler: ok
 [18:17:40] <ltinkl> that would be very much appreciated Kevin, not only by folks in fedora, but also in other distros
 [18:17:44] <Kevin_Kofler> Of course I'll have to work with Phonon upstream, I can't just do arbitrary API changes to Phonon.
 [18:17:45] <jreznik> rdieter: ltinkl is using it and already did some work, so maybe he's volunteer :D
 [18:18:02] <ltinkl> hehe not, not gonna touch anything starting with G
 [18:18:09] <ltinkl> :)
 [18:18:26] <rdieter> seems mandriva at least is using -gstreamer by default, may be worth talking to them too.
 [18:18:31] <jreznik> Kevin_Kofler: yes, it needs API changes... so lot of work...
 [18:19:06] <Kevin_Kofler> As for which Phonon to ship, that's another big mess.
 [18:19:21] <Kevin_Kofler> IMHO, as long as there are standalone tarballs, we should use them.
 [18:19:30] <rdieter> otoh, rumors have it that rhel6 will only support -gstreamer as well, so maybe rh could help out somehow too. :)
 [18:20:20] <Kevin_Kofler> Hmmm, than has been surprisingly silent in this Phonon discussion.
 [18:21:47] <rdieter> let's move on... we've got a bit to cover today, next: KDE-4.2.4 update status, ltinkl, Kevin_Kofler ?
 [18:21:58] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- KDE 4.2.4 update status".
 [18:22:08] <ltinkl> KDE 4.2.4 done for F10/F11, builds underway
 [18:22:37] <ltinkl> Kevin is backporting to F9
 [18:22:41] <Kevin_Kofler> For F9, I'm syncing things as I'm building them, and I'm doing the builds for the same packages ltinkl builds. :-)
 [18:22:56] <rdieter> cool, I'll continue to play tag-bot
 [18:23:00] <Kevin_Kofler> I think we're about halfway through the core packages or so.
 [18:23:05] Join nucleo has joined this channel (n=nucleo@80.73.6.156).
 [18:23:15] <Kevin_Kofler> Extragear is not started yet though.
 [18:23:20] <rdieter> do kdegraphics, then you can get to kdebindings
 [18:23:21] <ltinkl> tag bot won't be needed I guess :)
 [18:23:26] <Kevin_Kofler> Are the tarballs out yet? (They're already late.)
 [18:23:38] <Kevin_Kofler> rdieter: Hmmm, kdebindings built fine without a kdegraphics override.
 [18:23:45] Nick stickster is now known as stickster_food.
 [18:23:47] <ltinkl> I'll check the extra tarballs once I'm done with the core stuff
 [18:23:57] <ltinkl> and kde-l10n, not to forget this time
 [18:24:04] <rdieter> oh, stuff should be bc, ok
 [18:24:11] <Kevin_Kofler> Oh, and we'll need kdebase in the buildroot once we have konq-plugins to build (i.e. if extragear gets ready).
 [18:24:33] <ltinkl> konq-plugins need more than kdebase I think
 [18:24:37] <ltinkl> needs *
 [18:24:55] <Kevin_Kofler> It needs kdebase for Konqueror for sure.
 [18:25:02] <rdieter> so... stuff should get finished over the next day or so?
 [18:25:33] * jreznik has to leave today early... some brave man to prepare summary?
 [18:25:34] <Kevin_Kofler> ... and no other KDE stuff, I just checked.
 [18:25:37] Join petreu| has joined this channel (n=peter@p3EE3FAFC.dip.t-dialin.net).
 [18:25:52] <Kevin_Kofler> Only kdebase4-devel, cmake and gettext.
 [18:26:26] <ltinkl> jreznik: I'll do the summary today
 [18:27:10] <rdieter> next topic: Qt 4.5.1 updates
 [18:27:15] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- Qt 4.5.1 updates".
 [18:27:46] <wwoods> mdomsch: ping - can you remove the comment about bug 499321 and F10 in releases.txt? It's wrong and confusing people
 [18:27:48] <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=499321 medium, medium, ---, anaconda-maint-list, CLOSED RAWHIDE, preupgrade backtrace
 [18:28:08] <rdieter> the last blocker, imo, is amarok-2.1 landing... , for F-10 at least, means blocking on libgpod-0.7.0 batch update too
 [18:28:14] <wwoods> augh sorry
 [18:28:14] <mdomsch> wwoods, ok, can we turn F10 updates back on then?
 [18:28:23] * wwoods mischan
 [18:28:54] Join fab has joined this channel (n=bellet@bellet.info).
 [18:29:15] Quit jreznik has left this server ("leaving....").
 [18:29:24] <ltinkl> rdieter: what's the prob? libgpod not ready?
 [18:30:08] <than> hm, do we plan to push 4.5.1 in update?
 [18:30:08] <rdieter> libgpod-0.7.0 update for F-10, being a soname bump, requires a batch update for a bunch of stuff, and that update hasn't been made... yet (should be coming soon though)
 [18:30:32] <Kevin_Kofler> I had Amarok 2.1 building with libgpod 0.6, but then the libgpod maintainer decided to do the 0.7 upgrade so things got in some state of confusion.
 [18:31:02] <rdieter> Kevin_Kofler: I suppose we could do another build against libgpod-0.6, and not wait.
 [18:31:04] <Kevin_Kofler> Last I heard, the libgpod group updated was blocking on banshee ACLs.
 [18:31:20] <Kevin_Kofler> I guess one of us provenpackagers can fill it in.
 [18:31:35] <rdieter> otherwise, qt-4.5.1 is ready for stable updates, imo.
 [18:31:39] <Kevin_Kofler> Or we could nag the banshee maintainers to give Todd the ACLs he requested.
 [18:32:10] <than> are the qt blocker bug fixed?
 [18:32:50] <rdieter> yes (mostly), lemme get the details...
 [18:33:11] <Kevin_Kofler> Another issue is the kdelibs and kdeplasma-addons changes in the Qt update group, that can interfere with KDE 4.2.4 if we don't push Qt 4.5.1 to stable right now.
 [18:33:12] <rdieter> yep
 [18:33:25] <Kevin_Kofler> But we need an Amarok 2.1 rebuild against libgpod 0.6 for that.
 [18:33:30] <rdieter> Kevin_Kofler: nod, those (kdelibs in particular) needs to go stable first
 [18:33:49] <than> itif the qt blocker bugs are fixed
 [18:33:58] <Kevin_Kofler> Most likely with a deflated EVR (0.1.fc10.libgpod06?).
 [18:33:58] <rdieter> Kevin_Kofler: arg, that means I'll need to temp untag kdelibs-4.2.4, build amarok-2.1 against libgpod-0.6 and kde-4.2.3
 [18:34:03] <than> it's fine to push it in stable
 [18:34:20] <Kevin_Kofler> rdieter: You need to untag libgpod too if you didn't do so yet.
 [18:34:24] <rdieter> meh, we can work out the details after meeting, but it sounds like a plan
 [18:34:32] <rdieter> Kevin_Kofler: right
 [18:35:04] <rdieter> fyi, https://bugzilla.redhat.com/showdependencytree.cgi?id=Qt451&hide_resolved=1
 [18:35:42] <rdieter> rssnow has a temporary hack, amarok-2.1 helps, and the yum issue is worked-around via a well-placed Obsoletes
 [18:36:37] <rdieter> last item on the agenda was: https://bugzilla.redhat.com/show_bug.cgi?id=502953
 [18:36:38] <buggbot> Bug 502953: high, low, ---, than, ASSIGNED, kdm switches manually selected session after entering userid
 [18:36:49] <Kevin_Kofler> That's that session-button patch we dropped.
 [18:37:02] Join tibbs has joined this channel (n=tibbs@fedora/tibbs).
 [18:37:04] <Kevin_Kofler> It does the wrong thing.
 [18:37:05] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- https://bugzilla.redhat.com/show_bug.cgi?id=502953".
 [18:37:06] <than> does it fix the problem?
 [18:37:09] Quit petreu has left this server (Connection timed out).
 [18:37:22] <Kevin_Kofler> The patch causes the problem.
 [18:37:31] <Kevin_Kofler> It resets the button to Default after the user is selected.
 [18:37:46] <Kevin_Kofler> That's the wrong time to reset the session type.
 [18:37:47] <ltinkl> it fixes the problem by removing the feature :)
 [18:38:08] <than> i will take a look at the patch again
 [18:38:34] <than> it's ok to disable this patch in the meantime
 [18:38:36] <Kevin_Kofler> What problem was it intended to fix in the first place?
 [18:39:22] Quit sdziallas has left this server ("Ex-Chat").
 [18:39:33] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- Documenting patches".
 [18:39:45] <Kevin_Kofler> Hmmm, good point. :-)
 [18:39:48] Join RadicalRo has joined this channel (n=radical@193.254.32.144).
 [18:39:50] <ltinkl> yes :)
 [18:39:51] <than> Kevin_Kofler, if i remenber corectly the item is not selected in the combobox
 [18:39:56] <rdieter> slides into something else I wanted to discuss, documenting patches.
 [18:40:13] <than> the patch should resolve the issue
 [18:40:19] <Kevin_Kofler> than: OK, so that should be fixed, but where you did it is not the correct time to do it.
 [18:40:21] <rdieter> preferably via local or upstream bug report, else at least a line or 2 comment about it
 [18:40:49] <than> it seems so, i will take a look at the patch again
 [18:40:50] <rdieter> ltinkl: didn't you have other ideas on patch metadata too, you mentioned awhile ago?
 [18:40:53] <Kevin_Kofler> Because it'll reset the selection the human user made explicitly after a *nix user is selected from the list.
 [18:41:13] <ltinkl> well, I would go even further with the patch commenting
 [18:41:21] <ltinkl> let me dig some example
 [18:41:45] Quit warren has left this server ("Leaving").
 [18:41:46] <Kevin_Kofler> I think we also need to agree on the versioning: normally, the version in the patch is the version we're patching.
 [18:42:14] <rdieter> ltinkl: or if it's something bigger than what we have time to fully cover today, maybe send a proposal to fedora-kde list for discussion.
 [18:42:15] <Kevin_Kofler> But ltinkl has been using another format for patch backports recently, which uses the version of the first release the patch will be in upstream.
 [18:42:48] <ltinkl> yup, on the patch numbering: I'd suggest to number the patch to the version in which the bug is fixed
 [18:42:54] <ltinkl> the ucrrent way is too confusing
 [18:43:06] <Kevin_Kofler> I can see how that can help rebasing, but my main objection is that such a version doesn't necessarily exist and that it can change.
 [18:43:26] <Kevin_Kofler> (e.g. if upstream backports the patch, or possibly even reverts it)
 [18:43:48] <ltinkl> then we can keep it that way, or renumber ours as well
 [18:44:13] <ltinkl> in any case, our patch number will be more informative
 [18:44:16] <Kevin_Kofler> The name-versionbeingpatched-patchname.patch format is what almost all packages use in Fedora.
 [18:44:28] <ltinkl> which I don't like
 [18:44:31] <rdieter> I would gladly support almost anything that provides more information that the status-quo
 [18:44:35] <Kevin_Kofler> And versionbeingpatched will change if the package gets rebased.
 [18:44:35] <ltinkl> others' opinions?
 [18:44:40] <Kevin_Kofler> *patch
 [18:44:51] <Kevin_Kofler> If the patch gets rebased to a new release of the package.
 [18:44:52] Quit sereinity has left this server.
 [18:45:22] <Kevin_Kofler> So different patches will ideally have different names, helping those folks who keep all their patches in ~/rpmbuild/SOURCES.
 [18:45:29] <rdieter> I like ltinkl's idea, unless Kevin_Kofler, you have a better way of marking which patches have been upstreamed and to what version(s) ?
 [18:45:42] <Kevin_Kofler> (AFAIK, that's the logic which lead to that naming.)
 [18:46:20] <Kevin_Kofler> I think comments are better places to specify where the patch comes, or patch numbers (Patch10x vs. Patch20x as we've started using in some packages).
 [18:46:32] <ltinkl> anyway, we can discuss that after meeting I guess
 [18:46:36] <Kevin_Kofler> *comes from
 [18:46:44] <ltinkl> here's an example of what I thought with patch metadata:
 [18:46:46] <ltinkl> https://build.opensuse.org/package/view_file?file=kdm-dont-grab-mouse.diff&package=kdebase4-workspace&project=openSUSE%3AFactory
 [18:47:15] <Kevin_Kofler> "Authentication via a Novell Account is required to access openSUSE.org." Grrr...
 [18:47:17] <ltinkl> IMO it's worth the effort of putting a few lines at the beginning of each patch
 [18:47:21] <ltinkl> oops :)
 [18:47:32] <ltinkl> I'll post the patch somewhere else
 [18:48:04] <Kevin_Kofler> Why they can't allow downloading files without a login is beyond me, Fedora lets you do that just fine.
 [18:48:19] <ltinkl> does it work with http?
 [18:49:05] <rdieter> ltinkl: no
 [18:49:14] <Kevin_Kofler> http://lists.opensuse.org/opensuse-commit/2009-01/msg00579.html
 [18:49:21] <Kevin_Kofler> This contains that patch.
 [18:49:37] <ltinkl> bah ok, I'll post the complete proposal on patch numbering and patch metadata to the ML
 [18:50:01] <Kevin_Kofler> (see the end of the commit message)
 [18:50:06] <than> what is bad with our naming patch files
 [18:50:57] <ltinkl> than: that it has no informative value as to which version the patch applies to
 [18:51:04] <Kevin_Kofler> That it's not consistent, if we backport fixes from 4.2.4 to 4.2.3, most of us use kdefoo-4.2.3-bar.patch, ltinkl likes using kdefoo-4.2.4-bar.patch.
 [18:51:17] <rdieter> naming is a relatively minor detail, the more important issue to understand is to include information about the patch, what it is, what it fixes, when/where was it upstreamed, etc....
 [18:51:32] Nick stickster_food is now known as stickster.
 [18:51:58] <rdieter> if if the patch name can encapsulate some of that information, even better
 [18:52:27] <ltinkl> yup, and the patch itself should contain that information
 [18:52:43] <ltinkl> useful for backporting/moving the patch across versions
 [18:52:56] <Kevin_Kofler> Right, I hate patches with names like kdelibs-4.4.0-fixbug.patch and no comment as to what bug it fixes. ;-)
 [18:53:07] <than> most our patches already contain the information
 [18:53:16] <ltinkl> I always hate digging thru the spec file to find out what the patch does, what bug it fixes, what version it applies to etc.
 [18:53:29] <Kevin_Kofler> I can see keeping the name short, but that's what comments in the specfile or in the patch itself are for.
 [18:53:54] <Kevin_Kofler> ltinkl: Strange. I like having that information in the specfile.
 [18:54:01] <ltinkl> better have that info _in_ the patch file, you can immediately see what it does
 [18:54:02] <Kevin_Kofler> I'm not so much a fan of sticking it into the patch file.
 [18:54:02] <than> Kevin_Kofler, +1
 [18:54:19] <Kevin_Kofler> But having it in either place is better than not having it at all (like for the session-button patch).
 [18:54:20] <SMParrish> +1 from me as well. Specfile is best place for it
 [18:54:23] * rdieter doesn't care, as long as the info is somewhere
 [18:55:12] <rdieter> mild preference for in-patch, so other folks, like other distros , or upstream can get all that info by only looking at the patch too
 [18:55:56] <ltinkl> it gets more obvious with large packages, like kdebase-workspace with a large spec file and lot of patches
 [18:56:37] <Kevin_Kofler> Especially for those it's great to have all the comments in one place and not to have to open dozens of patch files to see what we changed.
 [18:56:47] <ltinkl> I'm definitely against naming patches like: kdebase-workspace-4.2.0-kde#180576.patch
 [18:57:03] <Kevin_Kofler> And it also means I have to edit only one file (the specfile), if I need to put comments in the patch, I have to hand-edit the patch file as well.
 [18:57:24] <than> ltinkl, i don't see any problem with this
 [18:57:34] <than> just add comment in the specfile
 [18:57:55] <ltinkl> ok, if the info is at least somewhere
 [18:58:04] <than> as we already did in our specfile
 [18:59:12] Join JSchmitt_ has joined this channel (n=s4504kr@p4FDD12DD.dip0.t-ipconnect.de).
 [18:59:13] <rdieter> here's a noble goal I think we can shoot for, for *every* patch in any kde core package, include metadata/documentation about it, a local/upstream bug report, and if not upstreamed, justification why it isn't.
 [18:59:31] Nick dwmw2 is now known as dwmw2_gonwe.
 [18:59:32] Nick dwmw2_gonwe is now known as dwmw2_gone.
 [18:59:48] <rdieter> target before kde-4.3.0 lands
 [19:00:23] <rdieter> but let's sort out the "how to do it" details first, of course.
 [19:01:06] <rdieter> looks like we're out of time, KDE SIG Meeting end.
 [19:01:09] <rdieter> thanks everyone.
 [19:01:23] Part MathStuf__ has left this channel ("Failure: Success!").
 [19:01:25] <Kevin_Kofler> Just a reminder: if you want KDE SIG represented in FESCo, vote for me! :-)
 [19:01:46] Topic rdieter sets the channel topic to "Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule".
 [19:02:06] * rdieter hands Kevin_Kofler a baby for a photo-op
